Method, system, and device for enabling micro-proximity location, detection and services

ABSTRACT

Techniques for enabling micro-proximity location, detection and services are described. One embodiment of the present invention pertains to location and micro-proximity services technology in conjunction with fixed or mobile devices using a type of low energy signals (e.g., Bluetooth Low Energy (BLE) technology). With the detected location before a specific object, various proximity services may be customized with respect to the specific object.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefits of U.S. Provisional Application No.62/038,368, filed Aug. 17, 2014, and entitled “Method and system forenabling micro-proximity detection, check-in, and information access toimprove customer engagement and advertisement accuracy”, which is herebyincorporated by reference for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally related to the area of retailcommerce. Particularly, the present invention is related to method,system, and device for enabling micro-proximity location, detection andservices.

2. Description of the Related Art

Modern smartphones typically incorporate a number of communicationssubsystems for location services. One exemplary incorporated subsystemuses the Global Positioning System (GPS) for basic outdoor locationservices. This GPS subsystem uses signals from multiple geo-stationarysatellites to determine the longitude and latitude position of asmartphone. Such a technology is effective out-of-doors with an accuracyof plus or minus two meters, but loses accuracy inside of buildings asthe building roof and structure scatters the satellite signals. The GPSsolutions also rapidly deplete the battery life of the mobile phone dueto the high power consumption used to satisfy the need for rapid updatedmeasurements from the geo-stationary satellites as the user changestheir location. While GPS is a solution for outdoor location services,there is a need for indoor location services.

Currently, the Wi-Fi signal strength between a smartphone and one ormore Wi-Fi Access Points (AP) has been used in conjunction with a GlobalPosition System (GPS) to determine the indoor location of the smartphone(the user thereof) within an establishment. By measuring received Wi-Fisignal strength of periodic broadcasts from the smartphone at each AP,Indoor Positioning System (IPS) software running on a Wi-Fi controllerconnected to each of the APs can triangulate on the location of thesmartphone, achieving an position accuracy within plus or minus onemeter. There are, however, several problems with this solution. In theGPS case, the application running on the smartphone is a moduledetermining the location of the phone. In the Wi-Fi IPS case, thelocation information is being collected and tracked by an externalprocessor. Getting information from the external processor to thesmartphone can be problematic because it typically requires anaffirmative action by the user with his/her smartphone. Such affirmativeaction might require the user to connect to a specific Wi-Fi network bya name identifier, or require the user to connect to a specific website,or require the user to open a specific application on the smartphone. Inaddition, the Wi-Fi IPS solution is relatively expensive to purchase,install, and operate since even the lowest-cost APs may cost from US$50to $75 per AP, and each AP location is restricted to a location withinthe reach of electric outlet power since Wi-Fi APs cannot operate onlimited battery power. Additionally, the Wi-Fi signals used forlocation-triangulation can be scattered and disrupted by fixtures andother movable structures within a building, and a radio phenomenoncalled multi-path, in which copies of the original Wi-Fi radio signalare created when the original signal is bouncing off interference fromindoor structures such as walls and ceilings. All of these problems maketriangulation accuracy below a couple of meters impossible. Thus thereis another need for solutions to determine a fairly precise locationindoor.

More recently a new technology for location and proximity services hasbeen introduced, called “Bluetooth Low Energy (BLE) beacons”, whichovercome some of the problems with the Wi-Fi IPS. They are easier toinstall than Wi-Fi APs. Like GPS, a smartphone performs the locationdiscovery so there is no need for a separate processor which is externalto the smartphone, no need to get location information to the phone fromanother processor, and the solution scales to any number of smartphones.BLE beacons are also typically battery operated making their placementin an establishment easier. However, BLE beacons do suffer someproblems. First, they are implemented using standard general-purposeBluetooth Low-Energy integrated circuits available from vendors such asTexas Instruments and Nordic Semiconductor. As they are designed to meetthe full range of Bluetooth specifications, they are quite overlysophisticated and costly devices.

Another technology incorporated into some smartphones that can enableand assist in providing location and proximity services is Near FieldCommunication (NFC). Unlike the Wi-Fi IPS or BLE beacons, NFC devicesare typically passive and only operate based on power received fromradio waves of a smart phone that physically touch or nearly-touch theNFC device. When a smartphone is placed within a millimeter or less toan NFC device, the device is activated and generates a near field radiofrequency signal that the smartphone can read. NFC devices are oftenpackaged as stickers that can be attached to movable structures or evendirectly to products. If a user touches the device with his smartphone,a resident app can read the information encoded in the device. NFC isalso sometimes used to enable short communication directly between twosmartphones, such as an exchange of photographs, when they “bump” orphysically touch each other. Clearly, NFC can be used for preciselocation and proximity services, however, it always requires that theuser take an action to place the smartphone physically against thedevice. Therefore, it cannot be used for passively locating a userwithin a radius of the device by either a mobile or fixed smartphone. Inaddition, passive NFC devices can only broadcast the same static contentand therefore cannot be easily protected so that only specific targetedmobile applications on smartphones are allowed to read the NFC devicestatic content. In other words, any third party smartphone applicationcan easily read such NFC devices and generate unwanted content to bedisplayed to the user on the smartphone.

Still another technology that currently exists for indoor location andproximity services is Radio Frequency Identification (RFID). While thesedevices are inexpensive and can be incorporated into stickers or badges,they suffer from two major disadvantages. First, most smartphones arenot equipped to read RFID tags while a typical mobile RFID reader maycost more than $1500 USD. Secondly, while fixed readers forautomatically and remotely locating RFID devices do exist, they requirea costly RF infrastructure consisting of deploying multiple RFIDantennas that are connected, by coaxial cables, to a shared reader. Thisshared reader is responsible for periodically energizing the RFIDdevices within the range of a given antenna and then listening for theirpresence and relative distance. The cost of the antennas, shared readerand infrastructure can run to many thousands of US dollars per readerinstallation. Hence there are many applications for which RFID is noteconomically viable for indoor location and proximity services.

SUMMARY OF THE INVENTION

This section is for the purpose of summarizing some aspects of thepresent invention and to briefly introduce some preferred embodiments.Simplifications or omissions in this section as well as in the abstractor the title of this description may be made to avoid obscuring thepurpose of this section, the abstract and the title. Suchsimplifications or omissions are not intended to limit the scope of thepresent invention.

In general, the present invention pertains to techniques for enablingmicro-proximity location, detection and services. According to oneaspect of the present invention, an electronic device, referred hereinas micro-proximity tag or simply tag, is used in conjunction with mobiledevices to provide the micro proximity location services. These tags maybe disposed at specific locations to be detected by a mobile device. Forexample, in a retail store, such tags are individually disposed nearspecific products being displayed. When a user carrying a mobile phonestanding near a product being displayed, the phone is caused to receivesignals from a tag disposed specifically for the product. The presenceof the user with respect to the product is detected.

According to another aspect of the present invention, some content inthe broadcast by such micro-proximity tags is encrypted and thereforesecurely protected so that only authorized mobile applications can readthe content. When the presence of the user before a specific product isdetected, the application running on the mobile phone receives a contentmessage targeted based on the specific product and causes the phone todisplay the message and send out a message (e.g., a visual or an audioalert).

According to still another aspect of the present invention, a pluralityof such tags are respectively disposed near specific objects across acomplex (e.g., a store). A module is executed in mobile devicesrespectively associated with a group of contestants, where thecontestants are contesting to discover the specific objects, forexample, to see promotions or advertisements thereof.

According to still another aspect of the present invention, a clientmodule is designed or configured to verify the purchase intent byconsumers by confirming their locations in front of a specific productdisplay, or that a consumer has approached a cash register after viewingan online advertisement of the product that was previously displayed onhis/her mobile device.

According to still another aspect of the present invention, the clientmodule is designed or configured to track assets and/or personnel withinan enterprise. In this application, a micro-proximity tag is attached toan asset and/or provided in a card form to a person. Fixed devices arestrategically placed around the enterprise. As assets and/or personnelenter into a range of the fixed devices, their presence and approximatedistance are reported periodically to a centralized device (e.g., aserver).

According to still another aspect of the present invention, the clientmodule is designed or configured to confirm the location of a consumerat a specific table in a restaurant in order to enable a wide variety ofrestaurant applications on mobile phones including menu display, servicerequest, bill presentation, payment, and etc.

According to still another aspect of the present invention, the tag isspecifically designed. Relevant parameters of the tag can be selectedand determined via a device (e.g., a mobile device) running the clientmodule in a predefined mode (e.g., write mode v. read mode). Not only isthe transmission power controlled to a small amount for detection of anearby device, but the tag also operates periodically (e.g., every 2 or10 seconds) to preserve the power driving it. The tag generates atransmission signal in compliance with a wireless technology standard sothat the transmission signal can be received by a commonly-used device(e.g., a smartphone). In addition, for simplicity, the tag is notdesigned as a transceiver but operates as a transmitter only.

According to yet another aspect of the present invention, the tag isspecifically designed to transmit variable powers according to apattern. At one moment, the transmission power is decreased to a minimumso that the tag can only be heard at a certain distance by devicesrunning the client module. At another moment, it may be desirable forthe tag to be heard by a device many meters away, in which case the tagis caused to broadcast a signal (e.g., data packets) at a hightransmission power. In any case, the signal is broadcast periodically orat predefined regular intervals, or this broadcast only occurs when adevice is detected within a predefined radius distance from the tag.

To ensure that the micro-proximity tags can be easily deployed withouttoo much on-site technical expertise, additional aspects of the presentinvention are developed as a server module or a cloud-based softwareplatform, referred herein as micro-proximity tag services, whichoperates with the tags, to enable simplified on-site association of adevice with a set of predefined actions (hereinafter as tag actions).Examples of the tag-actions include: opening a browser per a particularURL, opening a mobile application with a particular message, ornotifying a server of an interested customer. The micro-proximity tagservices are provided via a server running a server module specificallydesigned to implement one embodiment of the present invention. In oneembodiment, the micro-proximity tag Services allow an untrained retailemployee to use a mobile application to scan a UPC bar code of aspecific product or product display, and then read the micro-proximitytag, thereby forming an association between the product and the tag.

In addition, a platform is developed to enable a series of onlineinformation updates to confirm that a specific consumer has been locatedat a micro-proximity location(s) such as a product display or restauranttable. These updates might include the date and time that the consumerwas located by a specific device, the content or URL displayed to theconsumer, and location-based profile update of the consumer based on thespecific device location.

The present invention may be implemented in various ways including anapparatus, a method or a system. According to one embodiment, thepresent invention is a method for providing tag services, the methodcomprises: receiving in a server a message from a device caused toreceive a broadcast from a tag, wherein the tag is disposed at alocation, the broadcast includes at least one data packet, the messageis generated by a client module being executed in the device inresponding to the broadcast, and includes an identity of the tag,wherein a portion of the identity is encrypted; generating in the servera response to the message in accordance with the identity and a profileof a user associated with the device; sending the response to thedevice; causing the client module to digest the response, wherein theclient module is configured to cause the device to display a promotionmessage on a display screen of the device.

According to another embodiment, the present invention is a method forproviding tag services, the method comprises: providing a client moduleto be loaded in a device, the client module being automatically invokedwhen receiving a first broadcast from a first tag, wherein the clientmodule is registered with a server configured to provide the tagservices; generating by the client module a message when the device getsnear a second tag and receives a second broadcast from the second tag,the broadcast including at least one data packet; determining a distancebetween the device and the second tag, wherein the message includes anidentity of the second tag and the determined distance; transporting themessage to the server identified by a predefined link, wherein theserver is configured to generate a response to the message in accordancewith the identity and a profile of a user associated with the device;and causing the device to perform an action when the client modulereceives the response from the server.

According to still another embodiment, the present invention is a systemfor providing tag services, the system comprises: a plurality of tagsrespectively disposed across an establishment, each of the tags designedto broadcast to a short range and receive no signals when set to detecta presence of a mobile device coming nearby; and a server executing aninstalled server module configured to communicate with the mobile devicewhen the mobile device is caused to receive a broadcast including thedata packets from a tag, wherein the mobile device is loaded with aclient module registered with the server, the server is configured toreceive a message from the device and generate a response to themessage, and wherein the message includes an identity of the tag. Eachof the tags packaged in a small form factor operates periodically on oneor more batteries and comprises: an antenna; a state machine controllerprovided to randomize data packets for transmission in accordance with awireless technology standard; and a direct digital synthesizer providedto synthesize correct signal waveforms based upon data provided by thestate machine controller and generate data packets to be broadcast viathe antenna and to be received by the mobile device.

According to still another embodiment, the present invention is a tag tofacilitate tag services, the tag comprises: a battery, an antenna, awake-up timer to turn on and off operations of the tag per a predefinedtiming, wherein the tag acts as a transmitter to transmit a broadcast inaccordance with a wireless standard, a state machine controller providedto randomize data packets, a direct digital synthesizer provided tosynthesize signal waveforms based upon data provided by the statemachine controller and generate data packets to be broadcast via theantenna, and a memory space to store at least an identifier of one tagaction that is included in the broadcast and causes a device receivingthe broadcast to react per the tag action, wherein the device is loadedwith a client module that is configured to digest the broadcast, the tagaction is one of tag actions predefined on a server.

According to still another embodiment, the present invention is a methodfor determining a location of a tag, the method comprises: receiving ina server a message from a device caused to receive a broadcast from atag, wherein the device is disposed at a location, the tag is attachedto an object moving in an establishment, the broadcast includes at leastone data packet, the message is generated by a client module beingexecuted in the device in responding to the broadcast, and includes anidentity of the tag and an estimated distance determined by the clientmodule in reference to a transmission power of the broadcast received inthe device, updating a profile created for the object in reference tothe received message, wherein the profile includes informationpertaining to the identity of the tag, and requesting an updated messagefrom the device regarding the tag.

According to yet another embodiment, the present invention is a systemfor determining a location of a tag, the system comprises: a pluralityof devices respectively disposed around an establishment, each of thedevices executing a client module configured to cause the each of thedevices to receive a broadcast from a tag attached to an object, whereinthe tag is designed to generate the broadcast from time to time inaccordance with a wireless standard, a device receives the broadcastwhen the object moves close to the device, and a server, remotelylocated with respect to the devices, executing a server module tocommunicate with each of the devices and receives a message from thedevice when the device receives the broadcast from the tag, wherein themessage is generated by the client module being executed in the devicein responding to the broadcast, and includes an identity of the tag andan estimated distance determined by the client module in reference to atransmission power of the broadcast received in the device, the identityincludes a universally unique identifier (UUID) and an identifier (ID)of the tag, and wherein the ID is encrypted.

Different objects, features, and advantages of the present inventionwill become apparent upon examining the following detailed descriptionof an embodiment thereof, taken in conjunction with the attacheddrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the presentinvention will become better understood with regard to the followingdescription, appended claims, and accompanying drawings where:

FIG. 1 shows an exemplary retail environment in which one embodiment ofthe present invention may be practiced, where a plurality ofmicro-proximity tags or tags are respectively disposed across theenvironment;

FIG. 2 shows an functional block diagram of providing micro-proximitytag services according to one embodiment of the present invention;

FIG. 3 illustrates an internal functional block diagram of a mobiledevice that may be used in FIG. 1 or FIG. 2, wherein the mobile deviceis loaded with a client module provided by a service provider in FIG. 2;

FIG. 4 shows a Bluetooth modem implementation as commonly used as atransceiver;

FIG. 5 shows exemplary communication data flows among the devices shownin FIG. 2 and FIG. 3 according to one embodiment of the presentinvention;

FIG. 6 shows a Bluetooth Low-energy communications spectrum 600;

FIG. 7 depicts the anatomy of an Apple iBeacon packet;

FIG. 8 shows an advertisement packet per the iBeacon format;

FIG. 9 to FIG. 12 shows an encryption and decryption algorithm that maybe used to encrypt or decrypt a tag ID using a 6-bit key and randomizedlook up tables;

FIG. 13 shows a functional block diagram of a tag according to oneembodiment of the present invention;

FIG. 14 shows a conceptual representation of direct digital synthesizer(DDS) that may be used in FIG. 13;

FIG. 15 shows an output from the Direct Digital Synthesizer (DDS), wherea saw filter acts as a bandpass filter that filters out only the upperside of the spectrum around the fifth harmonic;

FIG. 16 to FIG. 19( d) show collectively an exemplary design of thestate machine controller that may be sued in FIG. 13; and

FIG. 20 shows a functional block diagram of a server module providingtag services according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The detailed description of the present invention is presented largelyin terms of procedures, steps, logic blocks, processing, or othersymbolic representations that directly or indirectly resemble theoperations of data processing devices. These descriptions andrepresentations are typically used by those skilled in the art to mosteffectively convey the substance of their work to others skilled in theart. Numerous specific details are set forth in order to provide athorough understanding of the present invention. However, it will becomeobvious to those skilled in the art that the present invention may bepracticed without these specific details. In other instances, well knownmethods, procedures, components, and circuitry have not been describedin detail to avoid unnecessarily obscuring aspects of the presentinvention.

Reference herein to “one embodiment” or “an embodiment” means that aparticular feature, structure, or characteristic described in connectionwith the embodiment can be included in at least one embodiment of theinvention. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment, nor are separate or alternative embodiments mutuallyexclusive of other embodiments.

The present invention pertains to a method, a platform, a device and anapplication each of which is designed to enable micro-proximitylocation, detection and services f. As used herein, any pronounreferences to gender (e.g., he, him, she, her, etc.) are meant to begender-neutral. Unless otherwise explicitly stated, the use of thepronoun “he”, “his” or “him” hereinafter is only for administrativeclarity and convenience. Additionally, any use of the singular or to theplural shall also be construed to refer to the plural or to thesingular, respectively, as warranted by the context. One of thebenefits, advantages and objectives in the present invention is todetect the presence of a user with respect to an object and provide aset of services in accordance with the presence.

Referring now to the drawings, in which like numerals refer to likeparts throughout the several views. FIG. 1 shows an exemplary retailenvironment 100 in which one embodiment of the present invention may bepracticed. A plurality of micro-proximity tags or tags are respectivelydisposed across the environment 100. Not specifically shown in FIG. 1,there are tags respectively placed near specific products on display.These tags are used to detect the presence of users standing in frontthe products to show their potential interests in these products.According to one embodiment, there are two such tags 102 located at theentrance and exit of the establishment 100. Depending on implementation,the tag at the entrance may activate a module if already installed inthe mobile devices carried by the users, alert a user to download amodule if not yet installed, to count users coming to the establishment100 and etc., the tag at the exit may activate the module in the mobiledevices to perform mobile payments, or to count users leaving theestablishment 100 and etc. The details of the module will furtherdescribed below.

As a user or customer 101 navigates in the establishment 100, his mobiledevice running the client module is caused to detect any signals fromthe deployed tags. When the user 101 stands before a displayed productfor a predefined period (e.g., 1 minute), the presence of his mobiledevice 101 is detected by the tag and reported to a computing device(e.g., a service server) remotely located with respect to the tag. Asfurther detailed below, triangulation may be used in the software mobileor a server to provide specific location based services 104. Inreference to the detected location, designated location and proximityservices may be provided to the user 101. Depending on what theestablishment 100 is for, promotions or coupons may be pushed to themobile device being carried by the user 101. In one embodiment,contactless or mobile payment may be executed when the user 101 isdetected to be leaving the establishment 101.

Referring now to FIG. 2, it shows an functional block diagram 200 ofproviding micro-proximity tag services according to one embodiment ofthe present invention. As shown, a tag 204 is located at a location 207,a mobile device 205 running a cleint module or an application (app) 406is caused to listen to a signal from the tag 204 over a communicationchannel 218 when in close proximity to it. It should be noted that themobile device 205 may be replaced with a fixed electronic device todetect the presence of a tag attached to an item or a card form carriedby a person, in which case the fixed device is disposed to detect thepresence of the tag. Those skilled in the art shall understand that theoperations of the tag and a device, regardless which one is mobile.remain substantially similar. Unless specifically stated herein, thedescription below is based on the assumption that a mobile device isbeing carried by a user while a tag is relatively stationary.

The device 205 is coupled to a network (e.g., the Internet or acombination of wireless and wired network) over a communication channel211. In one embodiment, both channels 211 and 218 are wireless. Alsocoupled to Internet is a micro-proximity tag services server or simplyservice server 201 and two or more control portals 208 and 209. In oneembodiment, the portal 208 is operated by a service provider (a.k.a.,micro-proximity tag service provider portal) while the portal 409 isaccessible by clients (a.k.a., client portals). Optionally, there areone or more additional servers such as client servers 202 and/orthird-party servers 203 coupled to the network.

The service server 201 is loaded and executes a software package (notshown) that is referred to a server module implementing one embodimentof the present invention. The micro-proximity tag services are providedby the server module via the server 201. According to one embodiment,the presence of the device 206 is detected by the tag 204, the device206 is caused to receive a message from the tag 204, the message inreturn causes the device 206 to communicate with the server 201, wherethe server 201 may be configured to send one or more promotion messagesto the device 206 with respect to an item attracting the attention of auser carrying the device 206. Depending on implementation, the promotionmessage may be a discount coupon, a further description of the item or alink to another website where different versions of the item may beshown. In one embodiment, the install module is designed to provoke thefunction of mobile payment or enable a regular payment towards aselected item on the device 204.

Referring now to FIG. 3, it illustrates an internal functional blockdiagram 300 of a mobile device that may be used in FIG. 1 or FIG. 2. Themobile device includes a microprocessor or microcontroller 302, a memorydevice 304, an input interface 306, a screen driver 308 to drive adisplay screen 310 and a network interface 312. To make the mobiledevice operable with deployed tags in an establishment, the mobiledevice is caused to install an application or a module 314 in the memorydevice 304. The module 314, also referred to herein a client module, isa software version implementing one embodiment of the present invention,and downloadable over a network from a library (e.g., Apple Store) or adesignated server.

In one embodiment, the module 314 is activated when a user of the mobiledevice is entering an establishment (e.g. an retail environment 100 ofFIG. 1). As a result, the mobile device is enabled to receive a type ofsignal when the mobile device is moved within a range of a transmitteror transceiver. According to one embodiment, the mobile device is turnedon by the module 314 to receive a low powered signal in compliance withthe Bluetooth standard, where a tag is disposed nearby and powered tobroadcast the low powered signal.

The input interface 306 includes one or more input mechanisms. A usermay use an input mechanism to interact with the device 300 by entering acommand to the microcontroller 302. Examples of the input mechanismsinclude a microphone or mic to receive an audio command from the user,or a keyboard (e.g., a displayed soft keyboard) to receive a texturecommand. Another example of an input mechanism is a camera provided tocapture a photo or video, where the data for the photo or video isstored in the device for immediate or subsequent use with anotherapplication module 316. The driver 308, coupled to the microcontroller302, is provided to take instructions therefrom to drive the displayscreen 310. In one embodiment, the driver 308 is caused to drive thedisplay screen 310 to display a promotion message received via thenetwork interface (e.g., Wi-Fi or 3G/LTE) in responding to the receivedsignal from the tag nearby. Besides receiving the Bluetooth-compliantsignal, the network interface 312 is provided to allow the device 300 tocommunicate with other devices via a designated medium (e.g., a datanetwork).

According to one implementation, the module 314 is specifically designedto enable the device 300 to receive the Bluetooth-compliant signal. Ageneric computer is incapable of or not equipped with the capability ofreceiving such a signal. As will be further described below, the module314 is configured to decrypt messages from a tag and cause the device300 to communicate with a designated server (e.g., the tax serviceserver 201 of FIG. 2).

FIG. 5 shows exemplary communication data flows among the devices shownin FIG. 2 and FIG. 3 according to one embodiment of the presentinvention. Except for the flow 500 between the tag 204 and the device205, all of the communication flows use a standard protocol (e.g.,Hyper-text Transfer Protocol or a secure version thereof) running over abidirectional session. In one embodiment, the flow 500 includes one-waybroadcast of a predefined signal (e.g., a BLE advertisement packet)which can be received by the device 205 when the tag 204 is within arange. The flow 501 operating between the device 205 and the server 201is managed by a cleint module 206 running on the device 205 to exchangeinformation about the tag 204 with the tag service module 219 beingexecuted on the server 201.

The flows 202, 203, and 204 are used to allow third-parties, clients,and tag service providers to access information about the operation ofand configure the behavior for the tag service module 219. Such accessmay be provided through the portals 208, 209, and 210 and usecommunication channels 212, 213, and 214, respectively with the networkand communication channel 215 to effect the complete flows. In addition,the flow 505 causes the tag service module 219 to exchange informationwith various modules operating on the client servers 202 viacommunication channels 215 and 216 together with the network. The flow506 allows the tag Services 210 to exchange information with thethird-party server 203.

A tag service provider is the entity (e.g., a corporation or anindividual) that provides various services to clients who typically ownand operate a location with deployed tags. An example of the clients mayinclude, but not be limited to, a retail chain (e.g., Macy's), anoperator of vending machines, or a vendor booth at an industry tradeshow. A third party is an independent entity that may form a partnershipwith either a tag service provider or a client or perhaps both. Anexample of such a third-party may be an ad tracking company thatanalyzes user actions and provides profile information about a userwhose device has been interacting with one or more tags in a location.

The tag services offered via the tag service module 219 include locationand proximity services. According to one embodiment, one version of theclient module 206 operates as a Tag Writer while another version of theclient module 206 operates as a Tag Reader. As further described below,either function may be embedded into the client module 206 that has adifferent overall purpose with the use of a Software Development Kit(SDK) that may be provided in accordance with the tag service module219. In one embodiment, the module 206 is configured as the Tag Writerdedicated to writing tags and the Tag Reader is functionallyincorporated into a different version of the module 206.

According to one embodiment, the basic functionality of themicro-proximity tag services being provided via the server 201 includesat least three processes: a monitoring and tracking process, a “find me”process and a user interaction process.

In the first process, the device 205 is caused to monitor itsenvironment listening for any signals from the micro-proximity tags thatmay be present nearby. The presence is detected via periodic receptionof data packets transmitted over a wireless channel (e.g., a Bluetoothsignal). This presence together with the RF power level at which thesedata packets are received are periodically reported to the server 201,where the micro-proximity tag service module 219 is configured toprovide location and proximity services in accordance with the detectedpresence.

The second process is applicable to cases where the device 205 is amobile type. In this process, the module 206 installed in the device 205is configured to select a tag (e.g., the tag 204) that the user wouldlike to find. The module 206 then guides the user to the immediatevicinity of the tag 204 by providing frequent distance estimates basedupon the RF power level at which the data packets being transmitted fromthe tag 204 are received, thus guiding the user to where the tag 204 islocated.

The third process also applies to the case where the device 205 is ofthe mobile type. In this case, three procedures are performed:

-   1. a client and/or third-party user defines a set of actions that    they would like to enable for or provide to the users when they are    near a specific location, such as immediately adjacent to a retail    shelf, an advertising display or a product. This set of actions is    called a tag action.-   2. the client and/or third-party user places a tag at a specific    location and associates it with a defined tag action.-   3. a user moves his device within the vicinity of the tag which then    triggers the previously defined tag action to occur.    The operations involved in these procedures are described in a more    specific manner below.

One of the functions provided by the tag services is to allow a clientand/or a third-party to create and manage the tag actions. The tagactions are a set of actions that a client and/or a third-party wouldlike to have performed when a given tag is read. Examples of possibleTag Actions are:

-   -   Opening a browser and causing the browser to display a given        Uniform Resource Locator (URL), where such a URL comprises a        base URL optionally concatenated with a text string specifically        assigned to the tag that was read;    -   Sending a message to the module 206 operating on the device 205,        where the message comprises a text string optionally        concatenated with a text string specifically assigned to the tag        that was read;    -   Sending a specific mobile advertisement or promotion to the        device 205 based upon a profile of the user with the device 205;    -   POSTing a message to an external server (such as client server        202 or third-party server 203) in which the message comprises a        text or binary string optionally concatenated with a text or        binary string specifically assigned to the tag that was read;    -   POSTing a message to a RESTFUL interface in which the message        comprises a text or numeric string optionally combined with text        or numeric strings specifically assigned to the tag that was        read; and    -   Taking no action.

A tag action may include one or more of these actions arranged in anyorder and include multiple instances of a particular type of action (forexample, POSTs to several different servers). A tag action is defined byaccessing the service module 219 via any of the appropriate portals: thetag service provider portal 208, the client portal 209, and thethird-party portal 210. Any action that can be pre-defined and executedby a computer could qualify as a tag action provided that the servicemodule 219 is configured to provide a mechanism for such actions to beso defined.

Once a tag action is defined, it can be assigned to one or more tagsbeing deployed. In one embodiment, assigning a defined tag action to oneor more Tags is performed through one or more of the portals. Ingeneral, a tag is uniquely identified with an identity. The identity maybe a tuple of values: a Universally Unique Identifier (UUID), and a TagID. This tuple is signified by the nomenclature [UUID, Tag ID].According to one embodiment, the module 206 is activated to select atag-action from those defined, then read an identity of a tag and directthe tag services 219 from the server 201 to conduct the association.According to another embodiment, the module 206 is activated to allow auser to enter an identification string, such as a Universal Product Code(UPC), which is sent together with the identity of the tag to the server201 to conduct the association between the tag and a tag Action that hasbeen modified by the identification string. According to yet anotherembodiment, a UPC reader may be incorporated into the module 206 toacquire the identification string.

Once a tag has been written, which means that an identity has beenassigned to a tag action, then a user with a device operating a clientmodule configured to implement the tag reader function shall invoke theaction or actions associated with the tag when the device is placed inclose proximity to the tag. In addition, the tag services being offeredvia the module 219 can also relate this identity to any tag that isdetected and read by the device. In both cases, The client module 206 isconfigured to cause the device 205 to receive a predefined signal fromthe tag 204 and send the identity thereof to the tag services offered onthe server 201. On the server side, the tag service (server) module 219is configured to decode and look up this unique identity and thenexecute one or more associated tag action(s). Other management and usageinformation is also gathered during this operation which will bedescribed more thoroughly in the disclosure below.

A micro-proximity tag may come in any shape and small in small in size.One of functions of the tag is to broadcast a type of signal commonlyreceivable by a mobile device (e.g., iPhone) or a dedicated stationarydevice. One example of such signal is BLE Advertisement Packets atdifferent RF power levels so that they can be commonly heard by adevice. In some cases, it may be desirable for a tag to be heard by adevice many meters away. In this case, a tag is designed to broadcast asignal (e.g., data packets) at a high transmission power. In othercases, it may be desirable for a tag to only be heard by a device only afew meters away, in which case, the tag is designed to transmit a signalat a low transmission power. In any case, the signal is broadcastperiodically or at predefined regular intervals, or this broadcast onlyoccurs when a device is detected within a predefined radius distancefrom the tag.

In one embodiment, a tag may transmit some data packets for a fixeddevice and some data packets for a mobile device at the same time. Toavoid obstructing important aspects of the present invention, thedescription below is not for the use of these packets, nor the variablepowers, but rather the combination of design choices that allow theelectrical circuit needed to accomplish this task to be substantiallysimpler, smaller, lower power and less costly than using a conventionalBluetooth integrated circuit.

According to one embodiment, the type of signal transmitted by a tag isBluetooth Low-energy (BLE) packets. FIG. 6 shows a Bluetooth Low-energycommunications spectrum 600. Communication between a BLE device and aSmartphone occurs on one of forty (40) 2 MHz wide radio-frequency (RF)channels centered on frequencies in the unlicensed Wi-Fi spectrum bandbeginning at 2.400 GHz up to 2.482 GHz. Each of the channels can supporta 1 MHz data rate using a form of frequency shift key (FSK) modulation.The channels are subdivided into three advertisement channels 601centered at 2.402 GHz, 2.426 GHz and 2.480 GHz and thirty-seven (37)data channels 602 centered at all of the channels not assigned foradvertisement. The data channels 602 are numbered 0 to 36 and theadvertisement channels 601 are numbered 37, 38, and 39, respectively.The BLE standards allow for a given BLE device to periodically broadcastfixed sized advertisement packets on one or more of the advertisementchannels 601 in order to notify other BLE devices of the existence ofthe given BLE device. The number of advertisement packets is determinedby an Advertisement Event that may include the given advertisementpacket transmitted only on BLE channel 37, on channel 37 then channel38, or on channel 37 then channel 38 then channel 39. According to theBluetooth standards, an Advertisement Event, however, always begins onchannel 37, however, other non-standard embodiments are also possible.

One embodied format of this type of broadcast packet has been specifiedby Apple Inc. for their iPhone and iPad-based location services. Thisformat and timing is called iBeacon. FIG. 7 depicts the anatomy of anApple iBeacon packet. A basic BLE packet includes a packet depicted inFIG. 7( a) consisting of a preamble octet 701, a four octet AccessAddress 702, a variable length Protocol Data Unit (PDU) 703 that can beas short as two octets and as long as thirty-nine (39) octets, and atwenty-four (24) bit (or three octet) CRC 704 calculated over the PDU703. For all packets, the preamble 701 is set to 0xAA. For advertisementpackets the Access Address 702 is set to 0x8E89BED6. FIG. 7( b) showsthe corresponding numbers. The PDU 703 includes two fields: a two octetheader field 705 and a payload field that can have up to thirty-seven(37) octets as specified in the length field 706 of the header 705. Thepayload for an advertisement packet includes a six octet AdvertiserAddress field 707, which may be the IEEE 802 address of the BLE deviceor simply a random data pattern and an Advertiser Data field 708. Theseformats are illustrated in FIG. 7( c) and FIG. 7( d). As depicted inFIG. 7( e) and FIG. 7( f), for the iBeacon format, the Advertiser Datafield includes two “AD” structures. AD structure #1 709 is a three octetfield indicating that this advertisement packet is a beacon, and ADstructure #2 710, a twenty-seven (27) octet field which follows Apple'sproprietary iBeacon format. As illustrated in FIG. 7( f), this format isindicated by the AD Type 711 equal to 0xFF, the Apple identifier 712 of0x004C. The final payload of this second AD structure is depicted inFIG. 7( g). It includes an identifier 713 set to 0x02, a length field714 set to 0x15, a sixteen (16) octet universally unique identifier(UUID) 715, two 2-octet information fields called the Major Identifier716 and the Minor Identifier 717 and a one octet transmit power 718which is the 2's complement representation of the beacon's transmitpower at a distance of one meter. The UUID 715 is used by the clientmodule to register for certain types of beacons. The Major 716 and Minor717 fields are used to say something unique about the specific beacon.The transmit power 718 allows the client module to determine theapproximate distance from the beacon by comparing the power at one meterto the power that the packet was actually received by the BLE receivercircuitry within the device running the client module.

In one embodiment, a tag uses the iBeacon format as described above andshown in FIG. 7. FIG. 8 shows an advertisement packet 800 per theiBeacon format. As shown in this figure, all of the standard iBeaconfields are used with one exception. It shall be noted that theAdvertisement PDU 804 type is set to 0x00 indicating that the AdvertiserAddress field 803 contains no valid information. However, in anotherembodiment, the Advertisement PDU could be set to 0x40 and a legitimateAdvertiser Address field 803 could be present. In addition, the iBeaconstandard TX Power value 805 is included and represents the RF power ofthe signal measured one meter away from the tag. The exception to theiBeacon format is that the Major identifier 716 and Minor identifier 717fields are combined into a single thirty-two (32) bit (4 octet) field801 which contains an encrypted version of a specific identifier (TagID) that, together with the UUID 802, uniquely identifies the Tag. Theability to make the tag specific to a given service provider using theUUID field 802 and to encrypt the Tag ID and place it in the encryptedTag ID field 801 are significant improvements over passive NFC devices.A passive NFC device Reader can, in principle, read any NFC device,whereas, the client module is typically configured to only receive theadvertisement packets from the tag, if it already knows and haspre-registered for the UUID 802. This allows a service provider to limitthe client module to read a given tag.

Once an identifier of an NFC device has been read, the location, productor shelf that it is attached thereto is also known and can be used bynon-client or non-service provider Apps to bypass the specific marketingcampaign or message desired by the client or the service provider. Forexample, once an NFC device identifier is known for a given SonyTelevision, and it only needs to be read once and stored in a databaseto do so, any Apps with access to such a database can identify the NFCdevice as referring to a Sony Television and take arbitrary, possiblyeconomically harmful action, such as presenting offers for competitiveproducts at a lower price.

As a tag ID is encrypted, subsequent reads of the same tag would notnecessarily result in the value in the encrypted Tag ID field 801 as itcan, in one embodiment, change over time. In one embodiment, thisencrypted Tag ID 801 changes as often as every hour.

There are many different ways to implement the encryption of the Tag IDto generate the encrypted Tag ID embedded in an advertisement packet. Inall cases, encryption is accomplished by operating on the Tag ID with analgorithm that is driven by the combination of a private key and apublic key. The encrypted value together with the public key aretransmitted to the decryption logic that uses the public key, togetherwith the private key that only the tag and the decryption logic know tore-create the original Tag ID. In some embodiments, the public key canbe implicit, such as the current GMT time. For the purposes of thisdetailed invention description, one particular algorithm is described,however, many other algorithms are possible.

One objective of encrypting the Tag ID is to ensure that reception of asingle advertising packet cannot be used to uniquely identify the tagwithout knowing the decryption algorithm. In the use case applicationsenvisioned for a tag, the encryption requirements need are not verystringent. Basically, a client or service provider wants to be insuredthat anyone attempting to decrypt the encrypted Tag ID 801 would need tostudy the advertisement packets for a long period of time.

One embodiment an encryption and decryption algorithm that meets theserequirements is described in FIG. 9 through FIG. 12. The basic ideabehind this embodiment is that sixty-four (64) encrypted versions of agiven Tag ID are calculated and stored in a tag. Further the tagcontains a circuit, further described below, that changes the encryptedTag ID that it is using in transmitted advertisement packets 800approximately every hour. This means that in order for a tag unique TagID to be recognizable to a client module without knowing the decryptionalgorithm would require that the tag be monitored for 64 hours and allof the possible encrypted values captured. For the use case applicationsenvisioned for the tag services, such an exercise would be onerous.

As depicted in FIG. 9, the Tag ID is a twenty-six (26) bit value calledT′<25:0> 901. This value is segmented into two thirteen (13) bit valuescalled A′<12:0> 902 and B′<12:0> 903. In addition, there is a six (6)bit key value called K<5:0> 904 which is incremented from 0x00 to 0x3F.Each value of K 904 points to an Encrypt A′ Table 905 and an Encrypt B′Table 906. Each of these tables contain a random arrangement of 8192values between 0 and 0x1 FFF in which none of the values is repeated inthe table. There are 8192! (factorial) ways of creating such tables and128 of them have been selected at random; sixty-four for the Encrypt A′side and sixty-four for the Encrypt B′ side. The values of A′ 902 and B′903 are used as the index into the table selected by K 904 presentingthe contents at these indices of A<12:0> 907 and B<12:0> 908. Thesevalues together with each successive value of K 904 are presented to abit combiner 909 to generate sixty-four (64) encrypted Tag ID valuesT<31:0> 910 which are stored into Tag 404. The operation of the bitcombiner 909 is depicted in FIG. 10 where the bits from values A< > 907,B< > 908, and K< > 904 are combined to form the encrypted Tag ID T<31:0>910. The reader will recognize that there are more than 31! (factorial)ways in which this encrypted Tag ID value could be created from thecomponent values and many other embodiments are possible.

FIG. 11 and FIG. 12 depict show an embodiment of how an encrypted Tag ID910 (and 801) is created using the algorithm described above, and can bedecrypted. The encrypted Tag ID 910 is first extracted from theappropriate field 801 in the Advertisement packet 800. As shown in FIG.11, the encrypted Tag ID 910 is applied to bit extractor 1101 to obtainthe two encrypted values A<12:0> 907 and B<12:0> 908 together with thespecific key K<5:0> 904. The value of K 904 is now used to select oneDecrypt A Table 1102 and one Decrypt B Table 1103. The values of A 907and B 908 are used as indices into these tables to look up the originalvalues A′<12:0> 902 and B′<12:0> 903, respectively which areconcatenated to form the original Tag ID T′<25:0> 901.The Decrypt ATables 1102 and the Decrypt B Tables 1103 are the inverses of theEncrypt A Tables 905 and the Encrypt B Tables 906 for each value of K904. That is to say they meet the following relationships:

Decrypt A((Encrypt A(N, K)), K)→N

Decrypt B((Encrypt B(N, K)), K)→N

where N ∈{0, 1. 2, . . . ,8191}.

This represents simply one embodiment of encryption algorithms. Manyother choices are also possible.

Referring now to FIG. 13, it shows a functional block diagram 1300 of atag according to one embodiment of the present invention. The diagram1300 may be better understood with reference to FIG. 14. A first uniqueaspect of the tag is that, because it is designed to only be detectableby a device (e.g., a smartphone) within one meter or so, itstransmission power can be extremely low. In one embodiment, the transmitpower measured at 1 meter distance is less than −90 dBm. This specificaspect allows for an entirely different design approach, called directdigital synthesis, to be used as compared to the generalized Bluetoothmodem designs used in more complex integrated circuits. A second uniqueaspect of the tag is, as it is a broadcast only device, that noBluetooth circuitry for reception is required.

As a comparison, FIG. 4 shows a Bluetooth modem implementation ascommonly used as a transceiver. It incorporates a full Bluetooth radio402, a 32 bit ARM processor 401, a large number of digital input/outputcapabilities 403, and a number of specialized circuits for measuringenvironmental conditions or connections to analog sensors such asaccelerometers 404. The design shown in FIG. 13 shows that there is noneed for these items that are typically costly and consume a lot ofpower, which if used in a tag in the present invention would make itimpossible to operate the tag on a battery power for an extended period(e.g., months).

Referring back to FIG. 13, a third unique aspect of one embodiment ofthe tag is that an Advertising event may include transmission of asingle Advertising packet as allowed for by the BLE standards. Thisunique aspect reduces by one-third the current necessary to transmitpackets as only one, rather than three packets are sent. A fourth uniqueaspect of one embodiment of the tag is that there are only sixty-fourversions of the Advertisement packet 800. This is illustrated in FIG. 8.As seen octets 0 through 37 and 42 are fixed for all packets, there aresixty-four (64) different fixed patterns for octets 38 through 41, andoctets 43 through 45 are calculated by circuitry. Hence one embodimentof the tag that has non-volatile storage for

[(37−0)+1]+[1]+[64*[(41−38)+1]]=295 octets

is sufficient to hold all versions of the packet that need to be sent.This unique aspect can be contrasted with the complex integrated circuit400 that require 128,000 to 256,000 octets of non-volatile storage 403.

As illustrated in FIG. 13, the design 1300 includes a number of blocksand other components. Without obstructing aspects of the design, onlyessential blocks are described herein in detail. A wake-up timer 1303 isprovided to wake up other blocks or components periodically (e.g., everyM milliseconds, wherein M can be set to 100 ms, 300 ms or 500 msdepending upon the specific strapping option). In one embodiment, it canbe strapped externally from the integrated circuit 1300. Block 1302 is aclock circuit that provides multiple internal reference clocks F₁ and F₂derived from external crystal 1309 operating at frequency F₁. Block 1301is a 320×8 bit non-volatile memory that contains configuration of fixedand variable packet information. This non-volatile memory can beprogrammed using external signals 1308.

Block 1305 is a state machine controller that executes a number offunctions. First, it activates the other blocks in the integratedcircuit 1300 to enable the transmission of one or more Advertisingpackets. Second, it fetches configuration and packet data from thenon-volatile Memory 1301, processes the data and presents them to thedirect digital synthesizer block 1306. Included in this sequence is avariable wait time between 0 and 10 ms which randomizes the transmissionof packets in accordance with the Bluetooth Low-energy standards. Third,it also contains digital circuitry for calculating the CRC value for agiven transmitted packet and a “whitening circuit” as specified by theBluetooth Low-energy standards. These standards-oriented capabilitiesare common and well known to those versed in the art and will not befurther explained here. In addition, the state machine controller 1305may optionally drive an LED circuit 1307 and make use of a proximitysensor 1314.

The direct digital synthesizer block 1306 synthesizes the correct signalwaveforms based upon the data provided by the state machine controller1305. This synthesized signal is presented to an external RF circuit1311 which includes a saw filter 1312 and an antenna 1313. The directdigital synthesizer block 1306 uses a higher frequency clock F₃ which isderived from lower frequency clock F₁ by the clock multiplier block1304.

An antenna 1313 can be implemented in any number of methods. Oneembodiment implements the antenna 1313 using the well-known “inverted F”printed circuit board structure with an underlying ground plane toinsure that all RF energy is directed through the front of the Tag 404.Ideally, the integrated circuit 1300 is powered by one or more batteries1310. All of the blocks are active only for a period of time determinedby the state machine controller 1305 which is activated by the wake-uptimer 1303.

The Integrated circuit 1300, crystal 1309, battery 1310, RF circuit 1311and optionally LED circuit 1307 and proximity sensor 1314 are packagedon a small printed circuit board and installed in a plastic housing1315. In one embodiment, the plastic housing includes an adhesivebacking for attaching to a shelf, a fixture or a product.

A conceptual representation of the direct digital synthesizer (DDS) isshown in FIG. 14. The central portion of the DDS is an N-bit accumulator1401 that sums the values presented to it by a multiplexer 1402 and theprevious accumulated sum from an N-bit latch 1403. This accumulatedvalue is latched by the N-bit latch 1403 by transitions of thehigh-speed clock 1404 operating at a frequency F₃ that is provided bythe clock multiplier 1304. The value presented to the N-bit accumulator1401 from the multiplexer 1402 is selected by the value on the datasignal 1405 which is presented to the DDS by the state machinecontroller 1305 described above. When a value on the data signal 1405 is‘0’, the N-bit value X is selected and presented to the N-bitaccumulator 1401. When the value on the data signal 1405 is ‘1’, theN-bit value Y is selected and presented to the N-bit accumulator 1401.The actual values of X and Y are determined by the frequency that onewants the DDS to output. The output 1408 is the most significant bit ofthe N-bit value stored in the N-bit latch 1403. This output 1408 isamplified through a buffer 1410 which has its output current regulatedto a maximum defined by a two-bit power value, Power 1409, provided fromthe state controller 1305 and used to drive the RF circuit 1311.

Since the BLE signal uses frequency shift key modulation, a digital ‘0’is represented by one frequency and a digital ‘1’ is represented byanother frequency. So the value of X is chosen to synthesize thefrequency corresponding to a digital ‘0’ and the value of Y is chosen tosynthesize the frequency corresponding to a digital ‘1’. The equationsfor calculating these values is as follows:

X=(F _(‘0’)−(M*F ₃))/F ₃*2^(N) and Y=(F _(‘1’)−(M*F ₃))/F₃*2^(N)

where:

-   -   F_(‘0’) is the frequency corresponding to digital ‘0’    -   F_(‘1’) is the frequency corresponding to digital ‘1’    -   N is the binary size of the values desired in bits    -   F₃ is the high-speed clock 1404    -   M is the harmonic of the high-speed clock 1404 that is being        selected (the value and significance of M is described below).

The values of X and Y are stored in a look-up table 1406. The specificoutput pair of values (X, Y) selected from the look-up table 1406 isdriven by the control signal 1407 from the state machine controller1305. As the purpose of the design is to output Bluetooth Low-energyAdvertisement packets on the Advertisement Channels 601, the pair values(X, Y) stored in the look-up table 1406 correspond to the frequenciesshown in Table 1.

TABLE 1 Frequencies for BLE Indices used for Advertisement packets BLEIndex Frequency for ‘0’ Frequency for ‘1’ 37 2401.75 MHz 2402.25 MHz 382425.75 MHz 2426.25 MHz 39 2479.75 MHz 2480.25 MHz

The frequency spectrum of the raw signal output 1408 can be quitecomplex. But in principle the output spectrum includes peaks that areequidistant on either side of the primary carrier frequency F₃. Sincethe output, at the digital level is either a 1 or a 0 that changes likethe edges of a square wave, the spectrum around the primary carrier F3is replicated at a smaller amplitude at the odd harmonics 3*F₃, 5*F₃, .. . etc. . . . Using a saw filter 1312 one of these spectral images canbe filtered out and presented to the Antenna 1313 as a single frequency.This is illustrated in FIG. 15 where the saw filter acts as a bandpassfilter that filters out only the upper side of the spectrum around thefifth harmonic. In other words, for the diagram in FIG. 15, M=5.

As seen, the N-bit accumulation function performed by the conceptual DDSshown in FIG. 14 is completely predictable if the starting value of theaccumulator latch 1403, the value of the Data 1405, and the value of theControl 1407 are known. Furthermore, while there are 2̂N possiblestarting values, a small subset of these could be preselected andprovide the best behavior as the value of Data 1405 transitions from 0to 0, 0 to 1, 1 to 0, or 1 to 1. Hence another embodiment of the DDS isto fetch a pre-calculated sequence of Output values 1408 based upon thelast Data 1405 value and the current Data 1405 value and shift thissequence through buffer 1410 using High-speed Clock F3 1404. In thiscase instead of implementing an accumulator, these pre-calculatedsequences would be store in read-only memory.

The significance of this approach cannot be understated. First, for atypical Bluetooth radio 402 of FIG. 4, the frequency synthesis mustoperate at the Bluetooth frequencies between 2400 MHz and 2482 MHz.These are very high frequencies that require analog integrated circuittechnologies. Since this Bluetooth Radio 402 is combined with digitallogic such as an ARM processor 401, such an approach requires acustomized mixed-mode integrated circuit fabrication facility. Incomparison, the design of the tag in FIG. 13 and outlined above is acompletely digital circuit that can be fabricated on the most common,low-cost digital fabrication line. Second, as the power consumption ofintegrated circuits is linearly proportional to the switching frequency,the ability to select the M^(th) harmonic, means that the digital logicconsumes 1/M^(th) of the power. Third, the number of componentsoperating at the highest frequency F₃ is very few. In anotherembodiment, the DDS circuit depicted in FIG. 14 can perform theaccumulation function in parallel operating at a frequency F₃/4 and usea SERDES at the output to further reduce the number of componentsoperating at the highest frequency. Fourth a workable, lowest powerdesign includes selecting the right values for N, F₃ and M, as theadvertisement frequencies for ‘0’ and ‘1’ are specified by the Bluetoothstandards.

In one embodiment, a tag is a direct digital synthesizer, where N=10,M=5, F₃=950 MHz, 1000 MHz, and 1025 MHz to generate signals for Channels37, 38, and 39, respectively, a saw filter covering 2400 to 2490 MHz isused and the accumulator 1401 and the latch 1403 circuitry isimplemented as four parallel slices. Other design choices are alsopossible.

In one embodiment, the design of the state machine controller 1305 isillustrated in FIG. 16 through FIG. 19( d). This embodiment implements amemory assignment of the 320×8 bit Non-Volatile Memory (NVM) block 1301as depicted in FIG. 16. As shown the fixed octets of the AdvertisementPacket 800 (see FIG. 8) are stored in NVM 1301 locations 0 through 38.The desired RF power level at which an advertisement packet 800 shouldbe transmitted is stored in location 39. This is a two-bit valueselecting up to four power levels. In one embodiment, these valuesspecify: 00: Transmit at −15 dBm, 01:Transmit at −20 dBm, 10:Transmit at−30 dBm, 11:Transmit at −40 dBm. The sixty-four (64) different valuesfor the encrypted Tag ID 801 are stored in NVM locations 64 through 319.In addition certain configuration values used by the state machinecontroller 1305 are stored in NVM locations 40 through 43. Theseconfiguration values are defined in table 2 and table 3 below.

TABLE 2 Configuration Parameters NVM Loca- tion Name Description 40ConfigFlags Configuration flags defined in table 3. 41 LedOnDurationNumber of Advertisement cycles that the LED should be turned on. 42LedOffDuration Number of Advertisement cycles that the LED should beturned off. 43 EncryptPageDuration Number of Advertisement cycles ÷ 256that a given encrypted Tag ID should be used before incrementing to thenext value.

TABLE 3 ConfigFlags Detail Bit Position Name Description 0-1PacketPerCycle Set to ‘00’ if special low-power mode is to be used Setto ‘01’ if packet sent on BLE channel 37 Set to ‘10’ if packet sent onchannels 37 and 38 Set to ‘11’ if packet sent on all three channels 2LedEnable Set to ‘1’ if an LED circuit is present. 3 ProximityEnable Setto ‘1’ if a Proximity Sensor is present 4 through 7 n/a Not Used

In this embodiment, the state machine controller 1305 executes a set ofsteps necessary to transmit one to three advertisement packets 800 atregular intervals defined by the wake-up timer 1303. The state machinecontroller 1305 has several state variables that it must maintain. Theseare:

-   -   LED_CTR: An eight bit down counter that is used to time the on        and off durations of the LED, if it is enabled.    -   LED_STATE: A single bit state that is used to indicate if the        LED is currently on or off.    -   ENCRYPT_PAGE: A six bit up counter that holds the current value        of K, the index for the stored encrypted Tag ID.    -   ENCRYPT_CTR: A sixteen bit counter used to measure the length of        time left for the current ENCRYPT_PAGE to be used.    -   INDEX_CTR: The index indicating what frequency should be used        when transmitting an Advertisement Packet. This is presented to        Direct Digital Synchronizer 1506 on Control lines 1407.        All of these state variables are initialized to 0 on power up.        In addition there are two other counters used by state machine        controller 1305 that are not preserved between Advertisement        Events. These are:    -   PKT_CTR: A down counter the number of Advertisement Packets that        should be sent for this Advertisement Event.    -   ADDR_CTR: A counter used to sequence through the octets of the        Advertisement Packet for transmission.    -   CRC: This is twenty-four one-bit registers used to calculate the        CRC for the packet being transmitted.    -   WHITNER: This is seven one-bit registers used to whiten the        output bit stream.

FIG. 17( a) through FIG. 17( c) shows a flowchart for the execution ofthe state machine controller 1305 according to one embodiment of thepresent invention. The first action of the state machine controller 1305is to set the Wake-up Timer [1701] then shut down and wait for this timeto expire. When the timer expires, an additional random wait interval isinserted to be in accordance with the Bluetooth specification. At theexpiration of this timer, the state machine controller 1305 fetches theconfiguration parameters from the Non-volatile Memory 1301 at 1702.

If the PacketPerCycle value is non-zero, it is initialized to thePKT_CTR value from the configuration while the INDEX_CTR is cleared.Otherwise, the PKT_CTR is set to ‘1’ and the INDEX_CTR is incrementedmodulo 3 at 1703. This special mode where PacketPerCycle is zeroimplements one embodiment where there is only one Advertisement Packetper Advertisement Event, however, each of the three Advertisementchannels (e.g. indices 37, 38, 39) are used sequentially.

The next set of shaded logic at 1704 operates to flash an LED on or offby counting down the off or on duration using counter LED_CTR and theconfigured values LedOffDuration and LedOnDuration, respectively. IfProximityEnable is set to ‘1’ then a test at 1705 to see if a proximitysensor 1314 of FIG. 13 detects the presence of a mobile device isperformed. If no device is present, then no packets are sent and thecycle completion logic described below is executed.

For clarity of description, it is assumed that LEDEnable andProximityEnable are set to ‘0’ so the ADDR_CTR is cleared, the CRC andWHITNER bits are initialized, the Clock Multiplier is set to either 950MHz, 1000 MHz or 1025 MHz as specified by INDEX_CTR. [1706]. Inaddition, the RF transmit power level is fetched from NVM 1301 location39 (see FIG. 16) and provided to the direct digital synthesizer 1306 at1706. In accordance with the Bluetooth standard, the CRC bits areinitialized to alternating 1s and 0s where the first bit is set to 1 andthe 24^(th) bit is set to 0. Also in accordance with the Bluetoothstandard, the WHITNER bits are initialized to the binary value of theBLE index that is being used. So for example, if the BLE index is forchannel 37 represented as 0100101 in binary, the first bit of theWHITNER is set to 1, the second to 0, the third to 1, the fourth bit to0, the fifth bit to 0, the sixth bit to 1 and the seventh bit to 0. Thechannel being used is captured by the state variable INDEX_CTR where‘00’ means channel index 37, ‘01’ means channel index 38, and ‘10’ meanschannel index 39.

As depicted in FIG. 17( b) and the value of ADDR_CTR is tested as alarge “case statement” at 1707. Depending upon the value of thiscounter, different steps are performed as described below:

-   -   If ADDR_CTR is less than 5, the contents of the NVM 1301 stored        at the address location of ADDR_CTR are fetched and transmitted        one bit at a time beginning with the least significant bit at        1708. This is because neither the preamble nor the Access        Address should be whitened or used in the CRC calculation. Upon        the transmission of each bit of an octet, ADDR_CTR is        incremented at 1718 and re-evaluated as a “case statement” at        1707.    -   If ADDR_CTR is between 5 and 37 inclusive, the contents of the        NVM 1301 stored at the address location of ADDR_CTR are fetched        and transmitted one bit at a time beginning with the least        significant bit [1709]. However, in this case, each bit is also        input to the CRC and applied to the WHITNER before being        presented to direct digital synthesizer 1306. Upon the        transmission of each bit of an octet, ADDR_CTR is incremented at        1718 and re-evaluated as a “case statement” at 1707.    -   If ADDR_CTR is between 38 and 41 inclusive, the encrypted Tag ID        is fetched from NVM 1301 based upon the ENCRYPT_PAGE state        variable. Each of these octets are transmitted one bit at a time        beginning with the least significant bit through the WHITNER to        the direct digital synthesizer 1306 at 1710, 1711, 1712, and        1713. Each of these bits are also presented to the CRC        calculation registers. Upon the transmission of each bit of an        octet, ADDR_CTR is incremented at 1718 and re-evaluated as a        “case statement” at 1707.    -   If the ADDR_CTR is 42, then the contents of NVM location 38 are        fetched can presented to CRC, WHITNER and DDS 1306 as above at        1714. Upon the transmission of each bit of an octet, ADDR_CTR is        incremented at 1718 and re-evaluated as a “case statement” at        1707.    -   If ADDR_CTR is between 43 and 45, inclusive, then each octet of        the CRC calculation are fetch where CRC_(—)0 is an octet        comprising bits 1 through 8 of the CRC registers where bit 1 is        the least significant bit of CRC_(—)0, CRC_(—)1 is an octet        comprising bits 9 through 16 of the CRC registers where bit 9 is        the least significant bit of CRC_(—)1, and CRC_(—)2 is an octet        comprising bits 17 through 24 of the CRC registers where bit 17        is the least significant bit of CRC_(—)2. Each of these octets        are shifted out, one bit at a time beginning with the least        significant bit and applied to the WHITNER before being        presented to DDS 1306 at 1715, 1716, 1717. Upon the transmission        of each bit of an octet, ADDR_CTR is incremented at 1718 and        re-evaluated as a “case statement” at 1707.    -   If ADDR_CTR is greater than 45, then the packet transmission is        complete and flow moves to the steps outlined at 1719 in FIG.        17( c).

As depicted in FIG. 17( c), once a packet has been transmitted, thePKT_CTR is decremented. If this counter is non-zero, then there arestill more packets to be sent. The INDEX_CTR is incremented to point tothe next transmission frequency, the Clock Multiplier is updated for thenext frequency, ADDR_CTR is cleared, CRC and WHITNER registers areinitialized and the logic flow returns to FIG. 17( b) as described above[1720]. If the counter is zero, then the countdown counter ENCRPYT_CTRis decremented and tested to determine if it is time to move to a newencrypted Tag ID value. If the ENCRYPT_CTR is non-zero, then this testif false and control returns to the top of FIG. 17( a), step 1701. Ifhowever, it is zero, then the test is true and the ENCRYPT_PAGE whichpoints to next value of encrypted Tag ID is incremented and theENCRYPT_CTR is re-initialized to the EncryptPageDuration value stored inthe configuration multiplied by 256 before the control returns to thetop at 1721 in FIG. 17( a).

The particular tag design described in the preceding paragraphsrepresent one of a number of ways such a design could be implemented.The particular embodiment does not preclude design approaches whereadvertisement packets of different formats, content, and RF transmitpower levels are transmitted, nor approaches where different choices ofBLE transmit frequencies are selected.

As described above with respect to FIG. 2 and FIG. 3, the installedmodule 314 of FIG. 3 operating on a device is designed and configured towork with the micro-proximity tag services being offered via the server201. Depending on implementation, there are two types of functionalitythat may be incorporated in the module 314: tag reader functionality andtag writer functionality. The tag reader functionality facilitates adevice to detect a tag when it is moved within the proximity of the tagand reports the detection to the tag services. The tag writerfunctionality facilitates a device to assign a tag to a tag action thathas been previously defined by a service provider, a client, or athird-party using the tag services. As described above, such assignmentcould be performed via an appropriate portal. However, there areoperational simplicities that result from being able to make thisassignment after a tag has been placed.

One embodiment of the tag reader functionality is depicted in FIG. 18(a) through FIG. 18( c). FIG. 18( a) depicts two approaches in which thetag reader functionality can be implemented as part of the module 314 ofFIG. 3. In both approaches, the module 314 runs on top of an OperatingSystem (OS) in the device 300 in FIG. 3. The OS provides access to theBluetooth hardware the device 300. Access to the hardware is enabled andcontrolled by use of an Applications Programming Interface (API). In oneembodiment, this API is a “Beacon API” and provides the ability for themodule 314 to register to be notified when any iBeacon formattedadvertisement packet is received by the device 300, matching the UUID ofa specific tag service provider and thus conveying the contents of theMajor 716 and Minor 717 fields which contain the encrypted tag ID.

In a related embodiment, the Beacon API provides distance informationbetween a tag and a device in addition to the Major 716 and Minor 717fields. Using one approach the tag reader functionality is embeddeddirectly into the module 314 which interfaces to the OS using the BeaconAPI. Using a second approach, the tag reader functionality isimplemented as a tag Software Development Kit (SDK). In this approach,the module 314 is not directly connected to the Beacon API but onlyindirectly as part of importing the SDK. In this case the SDK implementsthe tag reader functionality. These two approaches are depictedrespectively in FIG. 18( a).

FIG. 18( b) shows an exemplary start-up sequence for the client moduleto be used for the first time, where the install module implements thetag reader functionality. The first time the App 406 is invoked severalsteps must be executed. First it must secure the Smartphone 405 user'spermission to utilize various services such as: advertising and trackingservices, location services, and network services at 1801. Second, theApp 406 must register itself with the tag services 419 overcommunication channel 501 at 1802. Thirdly, it must register the ServiceProvider's UUID with the Smartphone's 405 OS at 1803. Once these stepsare complete, the App 406 is enabled to read Tags 404.

FIG. 18( c) shows a process or flowchart of how a tag is read accordingto one embodiment of the present invention. Depending on implementation,the process may be implemented in software or in combination of bothsoftware and hardware. Depending on where a device is located, theclient module in the device may be active or inactive waiting for the OSthere to activate it. When the device is in the vicinity of a tag andreceives one or more broadcasting packets (e.g., Advertising Packetsmatching the UUIP of a service provider), the OS notifies the clientmodule and passes 2 sets of octets (e.g., the Major identifier 716 andthe Minor identifier 717 of FIG. 7) at 1804. If deployed on a mobiletype, the device is caused to vibrate by the tag reader functionality inthe client module at 1805. In responding to the detection of thepresence, the device is caused by the client module to send a “sighting”message to the tag services via a sever at 1806.

According to one embodiment, a “sighting” message, showed as an example1812, is a JSON object containing a unique sequence number created bythe tag reader functionality to be used in any response message so that“sighting” and “response” can be matched. In the example shown in FIG.18( c), the “sighting” or message ID includes the UUID of the tag, theMajor identifier and the Minor identifier values which contain theencrypted Tag ID, and a distance of the device is seeing the tag whichis calculated by the client module (or the SDK therein) by comparing thereceived signal strength of the broadcast from the tag with a reference(e.g., the Tx Power value 805) which represents the calibrated signalstrength that should be measured if the device is a certain distance(e.g., 1 meter) away from the tag. In addition, the message ID includesthe GPS location of the device, an identifier of the client module andthe Advertising Identifier of the mobile device. The identifier of theclient module is provided to the user who chose to install the module inhis device (e.g., in his iPhone 6) and to incorporate the tag readerfunctionality for the micro-proximity tags. The GPS and AdvertisingIdentifier values are available from the OS. The GPS location of the tagis typically defined when the tag is registered with the service server.The GPS value in the message identifier 1812 is used by the tag servicesto determine if the tag has been moved. Once the message identifier 1812has been sent, the tag reader functionality waits for a response messageat 1807.

In this depicted embodiment of FIG. 8( c), if the device is a mobiletype, the responses could be:

-   -   A timeout at 1808 and an error message is presented to the user,    -   A directive at 1809 to open a browser pointed at a particular        URL,    -   A directive at 1810 to send a received message to the client        module for processing, or    -   A directive at 1811 to do nothing.    -   A directive at 1814 to notify the tag services per the distance.        FIG. 18( c) also shows a suitable “response” message, it is the        JSON object depicted as 1813. It includes a sequence number that        is sent in the original “sighting” message, a type field        indicating which of the above actions at 1809, 1810, 1811 or        1814 should be executed, and a message field to convey textual        information to the client module whose meaning is dictated by        the type field.

When a distance parameter is included in the response message. In thecases of actions at 1809 and 1810, the presence of a distance valuedirects the client module (or the SDK therein) to take the action onlywhen the device is moved to a distance less than or equal to thedistance value in “response” message 1813 from the tag. In the case of1814, the presence of the distance value indicates that the clientmodule (or the SDK therein) should notify the tag services when thedevice is a distance greater than the distance value in “response”message 1813 from the tag.

FIG. 19( a) through FIG. 19( d) show collectively a process or flowchartof performing tag writer functionality according to one embodiment ofthe present invention. As described above, “tag writing” constitutesassigning a tag action to a given tag 404 and in general is applicableto a mobile device. Unlike the tag reader functionality, the tag writeris performed by agents of a client or a third-party. Hence a specificapplication or the client module with the tag writer functionality isdesigned to fulfill the functions. Similar to the tag readerfunctionality, the tag writer functionality uses the OS in the deviceand Beacon API. FIG. 19( a) shows the start-up sequence for the firsttime as a tag writer. The writer shall register itself with the tagservices at 1901. Since only authorized agents should be performing thisfunction, credential information must be entered or exchanged andvalidated at 1902. Once this validation is complete, the client modulemust be signed in with the tag services at 1903.

At this point, the writer is registered with the OS to receive the UUIDof a specific service provider at 1904 in FIG. 19( b). The user isprovided with a number of choices for writing a tag. As shown in FIG.19( b), the user can at 1905:

-   -   “Clear a tag”; that is un-assign a tag from its current tag        action,    -   “Choose from list”, where the tag action to be assigned to a tag        is selected from a list of options,    -   “Enter a Code”, where a code is entered by an agent or a user,        and this code is used to determine the tag action to be assigned        to the tag, or    -   “Test a Tag” to see if it is working properly and what the tag        action is assigned.

If the “Clear a Tag” function is selected, a message is displayedtelling the user to place the device close to the tag at 1906. Thewriter then reads the Tag's Major and Minor fields sent from the OS andforwards these together with a “Clear Tag” command to the tag servicesover at 1907. Once a response is received from the tag servicesindicating the operation is complete, a message is displayed to the userat 1908 and the sequence is completed.

If “Test a Tag” function is selected, again a message is displayedprompting the user to place his device close to the tag 404 at 1909. Nowthe Tag information is read at 1910 just as the tag reader functionalitydescribed above. The user may verify that operation was successful bypressing a designated button (e.g., a Done button) at 1911.

FIG. 19( c) shows an exemplary operation of the tag writer functionalityif the “Choose from List” function is selected. In this case, the clientmodule in the device queries the tag services for a list of tag actionchoices that may be displayed on the device at 1912. The user selects anitem from the list at 1913, which prompts the module to query the tagservices for detailed information about the selected tag action at 1914and provide the user with the option to write it to the tag, cancel thetransaction, or return to the list to select a different tag action at1915. Once the proper tag action has been selected and the “write”action is pressed, the module again directs the user to place the hisdevice close to the tag in order to read the Major and Minor values ofthe tag at 1916. This information is forwarded to the tag services sothat the specific tag can be assigned with the selected tag action at1917. Once confirmation is received, a message is displayed to the userto confirm the completion of the sequence at 1918.

FIG. 19( d) shows an exemplary operation of the tag writer functionalityif the “Enter a Code” function is selected. The first choice presentedis when the user wants to enter the code manually or scan a UPC code at1920. If “Manual” is pressed, a dialog box may be presented for the userto enter the code at 1921. If the “UPC” button is selected, then a UPCscanner window is opened, the user lines up the UPC code to be scannedin a displayed window and the scanner automatically reads the code valueat 1922. The tag action associated with this code (either enteredmanually or scanned) is then fetched from the tag services and displayedto the user at 1923. If this is the desired tag action, then the userselects a “write” action or the user may select the “back” or “cancel”buttons if it is not the correct tag action at 1924. When the “write”action is pressed, the client module again directs the user to place hismobile device close to the tag in order to read the Major and Minorvalues of the tag at 1925. This information is forwarded to the tagservices so that the specific tag can be assigned with the selected tagaction at 1926. Once confirmation is received, a message is displayed tothe user to confirm the completion of the sequence at 1927.

Referring now to FIG. 20, it shows a function block diagram of a servermodule 2000 according to one embodiment of the present invention. Theserver module 2000 is specially designed and configured to provide thetag services, some of which has already be described above. As thoseskilled in the art, a general computer does not have the ability, norequipped with the necessary mechanism, to perform the tag servicesdescribed in the present invention. In one perspective, the servermodule 2000 may correspond to the server module 219 of FIG. 2 or FIG. 5,and is preferably loaded in a computing device (e.g., a server) or maybe distributed across a number of servers co-located in the same datacenter or distributed across multiple data centers. For simplicity ofdescription, FIG. 20 depicts a single server deployment.

As shown in FIG. 20, The server module 2000 includes a number ofprocesses, data stores, and databases. Those skilled in the art shallappreciate that the processes, stores or databases may be combined toless than those shown in FIG. 20 with departing from the intendedoperations of the server module 2000. According to one embodiment, anactivity log database 2003 is used to record every event executed on orprocessed by one of the processes running as part of the tag services2000. This would include such events as: tag reads, tag writes, clientlogins, client logouts, tag-actions created, modified, or executed, andmessages sent to other servers. In one embodiment, all of the events aresaved in a single database. In a second embodiment, the most commonevents such as tag reads and executed tag-Actions are stored in aseparate databases for performance reasons.

A database 2004 is provided to include information pertaining to aservice provider, a client, or a third party (collectively referred toas an agent) that makes use of the tag services. A tag database 2005 isprovided to include information on all tags that are deployed by anoperator using this particular tag services. A tag-action database 2006is provided to contain all tag-actions that have been defined by theoperator using this particular tag services. The registered app database2007 is provided to contain information concerning a number of copies ofthe module downloaded by users and deployed on their devices. When onemodule containing the tag reader or tag writer functionality isinstalled, the device is registered with the tag services before theread or write functionality can be performed.

An analytics database 2008 is provided to contain analytics informationthat has been created by an analytics processor 2017 while a profiledatabase 2009 is provided to keep a profile of each of the users whohave registered the downloaded module with the tag services to access aservice by reading a tag being associated with the tag services. Theprofile is created by a profile processor 2018 and made available to adynamic Ad & coupon generator 2021 and a dynamic message generator 2022.

An advertisement database 2010 is provided to contain advertisementrules and content used by the dynamic Ad & coupon generator 2021 and thedynamic message generator 2022 to present relevant advertisements to aclient module being executed on a mobile device. Although it is possibleto send other promotion messages to a user having a device running theclient module, the promotion messages including an advertisement or acoupon are generally related to a product the user has stopped to pay aclose attention to, where there is a tag disposed nearby.

A web server interface 2023 handles all HTTP or HTTPS communication witha tag service provider portal 408, client portals 409 or third-partyportals 410. The web server interface 2023 allows an agent to configureor manage the tag services 419, for example, using conventionalweb-based mechanisms such as HTML. As such it passes messages andcreates pages for interacting with the management processes in acontroller portion including: a provider manager 2013, a client Manager2011, and a third party manager 2012.

A message handler 2024 handles all messages to and from a client moduleresiding on devices that may be caused to receive broadcasts fromdeployed tags. In one embodiment, it forwards messages received from adevice to and from a tag message decoder 2019 and a tag responseprocessor 2029, respectively. In one embodiment, the messaging structureused for communication with the module is a RESTFUL interface using HTTPor HTTPS and JSON element encoding. In another embodiment, the GoogleData format is used for the messaging exchanges.

The message server 2025 handles all server-to-server messages betweenthe tag services processes and one or more client servers 402 and one ormore third-party servers 403. This communication occurs acrosscommunication flows 505 and 506, respectively via Internet InterfaceServices 2002. The message exchange occurs between these servers andseveral of the processes within the Controller portion of the MVCarchitecture, but primarily with the Tag Response Processor 2020.

The controller portion implements all of the control logic for the tagservices. These control processes can be grouped into four categories:

-   -   The managers that are responsible for managing the primary        entities: tags, tag-actions, modules, provider, clients or a        third-party.    -   Background processes that analyze the activity of a device        reading a tag to create analytics, profiles of the service usage        and attributes, and interests of the users.    -   Utility processes that provide dynamic message information for        real-time processing elements.    -   The real-time processing elements responsible for receiving,        validating and responding to tag readers and tag writers        implemented as part of the client module.

The manager processes shown in FIG. 20 represent one embodiment of animplementation of this functionality within the tag services and aredescribed in the following paragraphs.

The provider manager 2013 controls all of the information needed by amicro-proximity service provider. This includes user information whichis retained in the user database 2004. The primary interface to thisprocess is via the server interface 2023.

The client manager 2011 controls all information pertaining to a clientwho subscribes to the tag services. This includes information pertainingto locations of all tags, a client server, and a client module, andclients agents which are retained in the user database 2004.

The third-party manager 2012 controls all information pertaining to thethird-parties who are partnered with clients and/or service Provider andsubscribe to the tag Services. This includes information pertaining toclients, third-party servers, client modules and third-party agents allof which are retained in the user database 2004.

The tag manager 2014 manages all actions and activities associated withthe deployed tags 404 being used as part of the tag services. This wouldinclude information about the location of the tags, what tag-actionsthey are assigned to, with which a client or third-party that they areregistered, their specific unique tuple [UUID, TagID], and how long theyhave been in operation. In the depicted embodiment shown in FIG. 20,this information is stored in the tag database 2005 and the primaryprocess that uses the tag manager services is the tag message decoder2019.

A tag-action manager 2016 is provided to manage all tag-actions thathave been configured by the users of the tag services. In the depictedembodiment shown in FIG. 20, this information is stored in thetag-action database 2006 and the primary process that uses its servicesis the tag response processor 2020.

The app manager 2015 manages information pertaining to all versions of aclient module that have implemented to include either a tag reader ortag writer function or both as part of their operation. all of theclient modules must be registered with the manager 2015 prior to beingable to read or write a tag. This process manages the registrationprocess and retains the pertinent registration information. In thedepicted embodiment as shown in FIG. 20, this information is stored inthe registered app database 2015 and communicates primarily with the tagresponse processor 2020 and the app message handler 2024.

A background process depicted in FIG. 20 represents an implementationwithin the tag services: an analytics processor 2017 reads the activitylog database 2003 and analyzes, categorizes, accumulates, and summarizesmany discrete actions recorded there into statistics that can be used togenerate usage reports for a provider, clients, or third-parties. Thesestatistics are preserved in the analytics database 2008. The analyticsprocessor 2017 generates these reports either on demand, or on apre-defined schedule, for the provider, clients, and third-parties ashas been previously configured via their respective portals (e.g., theportals 208, 209, 210) and the manager processes 2013, 2011, 2012,respectively.

A profile updater 2018 is responsible for maintaining and updating aprofile for each user who has registered to opt to the tag services. Itdoes so by reading the activity log database 2003, filtering andcorrelating which users, identified by an advertiser ID, and accessinginformation about which products or services identified in the tagactions that they have requested by reading the tags. Aspects of a userprofile that are updated include:

-   Commercial category (interest in a particular product or service)    -   Purchase propensity    -   Stage within purchase cycle-   Location category    -   Frequency, time-of-day, length of visit, first-time or repeat        visit    -   Next-hop relationship    -   Geography-   Demographics and psychographic defined commercial categories-   Lifestyle-   Other    -   Brand loyalty    -   Frequency of purchase    -   Life stage/life changing events    -   Micro-clusters defined by a client        The user profile information is retained in the profile database        2009.

The utility processes depicted in FIG. 20 represent an implementation ofthe tag services and are described in the following paragraphs. Uponrequest from the tag response processor 2020, the dynamic Ad & coupongenerator 2021 uses the profile database 2009 and the advertisementdatabase 2010 to generate a targeted, specific advertisement for a givenuser in response to that user reading a tag. For example, the tag actionassociated with a given tag that has been read might be to send a mobileadvertisement to a mobile device. The selection of the appropriateadvertisement would be predicated on knowing something about the userthereof, which is available in the profile database 2009, and the typeof advertisement campaign currently in flight, which is available in theadvertisement database 2010.\

The dynamic message generator 2022 performs a similar function as thedynamic Ad & coupon generator 2021. However in this case, a customizedmessage is sent to a client (e.g., a client server 202 or a third-partyserver 203). For example, a message may be sent to an advertisingnetwork server indicating that a user with a given advertisement ID iscurrently shopping at a particular store, making inquiries about aparticular type of product. This directive can be defined as part of atag action and requested by the tag response processor 2020. The profileof the user together with rules regarding what information can be sharedare stored in the profile database 2009 and advertisement database 2010,respectively.

The real-time processes depicted in FIG. 20 represent one embodiment ofthe tag services 2000. The tag message decoder 2019 receives messagesfrom a client module via the App message handler 2024. One embodiment ofsuch a message is the JSON sighting message 1812. Using the Tag IDdecryptor described above and illustrated in FIG. 11 and FIG. 12, thetag message decoder determines the unique Tag ID from the major andminor values included in the sighting message. This together with theother fields in the sighting message 1812 and the IP Address of thedevice reading the tag are sent to the tag response processor 2020 forprocessing.

The tag response processor 2020 is designed to responsible for acceptingthe incoming sighting messages and other messages from a client moduleand determining what the response should be based upon the decrypted TagIDs, UUIDs, and Application ID presented to it by the tag messagedecoder 2019. It uses the Tag ID and UUID to query the tag manager 2014for all tag actions identifiers associated with this particular tag.With this information, it queries the tag action manager 2016 todetermine what tag actions must be executed. Because there may bemultiple client modules that are sending sighting messages 1812 for thesame tag, the tag response processor 2020 must query the app manager2015 to determine which client module has the precedence. Based upon thetag actions that need to be executed, dynamic ads or coupons may need tobe generated by the dynamic Ad & coupon generator 2021 and dynamiccustomized messages might need to be generated by the dynamic messagegenerator 2022. Lastly, the tag response processor 2020 executes therequested tag action by sending the appropriate response messages, suchas response message 1813 to the appropriate client module via themessage handler 2024 and/or to the client server and/or a third-partyserver via a message server 2025.

The present invention has been described in sufficient detail with acertain degree of particularity. It is understood to those skilled inthe art that the present disclosure of embodiments has been made by wayof examples only and that numerous changes in the arrangement andcombination of parts may be resorted without departing from the spiritand scope of the invention as claimed. While the embodiments discussedherein may appear to include some limitations as to the presentation ofthe information units, in terms of the format and arrangement, theinvention has applicability well beyond such embodiment, which can beappreciated by those skilled in the art. Accordingly, the scope of thepresent invention is defined by the appended claims rather than theforgoing description of embodiments.

We claim:
 1. A method for providing tag services, the method comprising:receiving in a server a message from a device caused to receive abroadcast from a tag, wherein the tag is disposed at a location, thebroadcast includes at least one data packet, the message is generated bya client module being executed in the device in responding to thebroadcast, and includes an identity of the tag, wherein a portion of theidentity is encrypted; generating in the server a response to themessage in accordance with the identity and a profile of a userassociated with the device; sending the response to the device; causingthe client module to digest the response, wherein the client module isconfigured to cause the device to display a promotion message on adisplay screen of the device.
 2. The method as recited in claim 1,wherein the tag is one of a plurality of tags deployed by a serviceprovider in an establishment, the tag is uniquely identified by theidentity including a universally unique identifier (UUID) and anidentifier (ID) of the tag.
 3. The method as recited in claim 2, whereinthe broadcast includes an identifier of a tag action, the messagereceived in the server includes the identifier of the action, andwherein said generating in the server a response to the messagecomprises: looking up in a list of actions what action the client moduleneeds to perform per the identifier of the action received in themessage; and including the action in the response to be sent to thedevice.
 4. The method as recited in claim 3, wherein the client moduleis registered with the server so that only the registered client moduleis configured to read the encrypted portion of the identity.
 5. Themethod as recited in claim 3, further comprising: determining which ofthe tags has been read by the device with reference to the identity ofthe tag; and determining how far the device is from the tag by a powermeasurement on the broadcast.
 6. The method as recited in claim 5,wherein the server is loaded with a server module including a databasedesigned to maintain a list of tag actions, each of the tags isassociated with at least one of the tag actions.
 7. The method asrecited in claim 6, wherein the client module has been registered withthe server module, the profile of the user is created and updatedwhenever the device is caused to acknowledge the receipt of a broadcastfrom one of the tags.
 8. The method as recited in claim 3, wherein theidentity includes at least data representing a distance and a locationof the tag with respect to the device, and said generating in the servera response to the message in accordance with the identity and a profileof a user associated with the device comprising: analyzing the distanceand the location of the tag; and determining a client action the clientmodule is supposed to perform.
 9. The method as recited in claim 8,wherein, upon receiving the response, the client module is configured tocause the device to open a browser automatically filled up with aparticular universal resource locator (URL).
 10. The method as recitedin claim 8, wherein, upon receiving the response, the client module isconfigured to cause the device to report how far the device is from thetag and take an action only when an updated distance to the tag is lessthan the distance included in the response.
 11. The method as recited inclaim 8, wherein, upon receiving the response, the client module isconfigured to cause the device to report how far the device is from thetag and report to the server only when an updated distance to the tag isless than the distance included in the response.
 12. The method asrecited in claim 2, wherein the device is a smartphone carried around bythe user, the establishment displays a number of items, each of the tagsis disposed near one of the items, the smartphone receives the broadcastfrom one of the tags when the user stands before an item associated withthe one of the tags for a predefined period.
 13. The method as recitedin claim 12, further comprising: receiving a note in the server that atransaction has happened with respect to the item; and updating theprofile of the user.
 14. The method as recited in claim 13, wherein theestablishment is a retail store, the items are displayed products, themethod further comprising: sending a special message from the server tothe smartphone when the smartphone receives a broadcast from a speciallydesignated tag, wherein upon receiving the special message, the clientmodule is configured to cause the smartphone to initiate a mobilepayment to complete the transaction.
 15. A method for providing tagservices, the method comprising: providing a client module to be loadedin a device, the client module being automatically invoked whenreceiving a first broadcast from a first tag, wherein the client moduleis registered with a server configured to provide the tag services;generating by the client module a message when the device gets near asecond tag and receives a second broadcast from the second tag, thebroadcast including at least one data packet; determining a distancebetween the device and the second tag, wherein the message includes anidentity of the second tag and the determined distance; transporting themessage to the server identified by a predefined link, wherein theserver is configured to generate a response to the message in accordancewith the identity and a profile of a user associated with the device;and causing the device to perform an action when the client modulereceives the response from the server.
 16. The method as recited inclaim 15, further comprising: causing the device to initiate a procedurefor the user to complete when receiving a third broadcast from a thirdtag.
 17. The method as recited in claim 16, wherein the first tag islocated at an entrance of an establishment, the second tag is disposednear an object, and the third tag is located at an exit of theestablishment.
 18. The method as recited in claim 17, wherein theestablishment is a retail store, the device is a smartphone, the objectis a product on display, and the procedure is an transaction related tothe product.
 19. The method as recited in claim 15, wherein the tag isone of a plurality of tags deployed by a service provider in theestablishment, the tag is uniquely identified by the identity includinga universally unique identifier (UUID) and an identifier (ID) of thetag.
 20. The method as recited in claim 19, wherein the second broadcastincludes the identity of the tag and an identifier of a tag action. 21.The method as recited in claim 20, wherein the tag action is one of tagactions predefined and is assigned to the tag prior to the tag put intooperation.
 22. The method as recited in claim 21, wherein the tag actioncauses a text to be displayed on the device, wherein the text isconcatenated with a text string specifically assigned to the tag. 23.The method as recited in claim 21, wherein the tag action causes aspecific mobile advertisement or promotion to be displayed on the device205 based upon a profile of the user with the device.
 24. The method asrecited in claim 19, wherein content in the second broadcast isencrypted so that only the registered client module is configured toread the content.
 25. The method as recited in claim 19, wherein theresponse from the server includes a client action the device is supposedto perform.
 26. The method as recited in claim 25, upon receiving theresponse, further comprising: causing the device to open a browserautomatically filled up with a particular universal resource locator(URL).
 27. The method as recited in claim 25, upon receiving theresponse, further comprising: causing the device to report how far thedevice is from the second tag and take an action only when an updateddistance to the tag is less than the distance included in the response.28. The method as recited in claim 25, upon receiving the response,further comprising: causing the device to report how far the device isfrom the tag and report to the server only when an updated distance tothe tag is less than the distance included in the response.
 29. Themethod as recited in claim 25, wherein the device is a smartphonecarried around by a user, the establishment displays a number of items,each of the tags is disposed near one of the items, the smartphonereceives the broadcast from one of the tags when the user stands beforean item associated with the one of the tags for a predefined period. 30.The method as recited in claim 15, wherein said determining a distancebetween the device and the second tag: measuring a radio power of thesecond broadcast; and looking up the measured radio power in alook-up-table to conclude how far the device is located from the secondtag.
 31. A system for providing tag services, the system comprising: aplurality of tags respectively disposed across an establishment, each ofthe tags designed to broadcast to a short range and receive no signalswhen set to be detected by a mobile device coming nearby, wherein eachof the tags packaged in a small form factor operates periodically on oneor more batteries and comprises: an antenna; a state machine controllerprovided to randomize data packets for transmission in accordance with awireless technology standard; and a direct digital synthesizer providedto synthesize signal waveforms based upon data provided by the statemachine controller and generate data packets to be broadcast via theantenna and to be received by the mobile device; a server executing aninstalled server module configured to communicate with the mobile devicewhen the mobile device is caused to receive a broadcast including thedata packets from a tag, wherein the mobile device is loaded with aclient module registered with the server, the server is configured toreceive a message from the device and generate a response to themessage, and wherein the message includes an identity of the tag. 32.The system as recited in claim 31, wherein the identity including auniversally unique identifier (UUID) and an identifier (ID) of the tagand the broadcast includes the identity of the tag and an identifier ofa tag action.
 33. The system as recited in claim 32, wherein the serveris further configured to: determine which of the tags has been read bythe device with reference to the identity of the tag; and determine whataction the client module needs to cause the device to perform withreference to the identifier of the tag action.
 34. The system as recitedin claim 31, wherein the server comprises at least a database designedto maintain a list of tag actions, each of the tags is written with atleast one of the tag actions.
 35. The method as recited in claim 34,wherein the database includes at least a profile for a user associatedwith the device, the profile is updated whenever the device is caused toacknowledge the receipt of a broadcast from one of the tags.
 36. Themethod as recited in claim 31, wherein the identity includes at leastdata representing a distance and a location of the tag with respect tothe device, and the server module is configured to: analyze the distanceand the location of the tag; and determine a client action the clientmodule is supposed to perform.